Indagación de Requerimientos

Tema 4 — Técnicas y Herramientas para Elicitación de Requisitos

Ingeniería de Requerimientos de Software | Nivel: Medio

👉 Usa las flechas del teclado o los botones para navegar →

CASO DE ESTUDIO

Davisnet® — Estaciones Meteorológicas

La compañía Davisnet® se dedica a la fabricación y venta de estaciones meteorológicas para usos desde el doméstico hasta el agrícola.

📊 Instrumentos de medición

Cada estación está dotada de: barómetro, termómetro, anemómetro, sensores de humedad interior, recolector de lluvia, sensores de radiación solar y sensores de humedad en el suelo.

El desafío

Davisnet® desea ofrecer a sus clientes la capacidad de monitorear la información de estos sensores desde una página de Internet. Ha contratado a una empresa desarrolladora de software y te han asignado la coordinación de la ingeniería de requerimientos.

❓ Pregunta 1

¿Cuál sería el primer paso que debes realizar para comenzar con la documentación de los requerimientos?

❓ Pregunta 2

¿A quién deberías consultar para conocer las funcionalidades del sistema?

❓ Pregunta 3

¿Qué técnica de indagación deberías utilizar para especificaciones completas y claras?

Estas preguntas las resolverás al final de este tema →

4 — INDAGACIÓN

¿Qué es la Indagación de Requerimientos?

La indagación (o elicitación) de requerimientos es el proceso de recopilar, analizar y documentar las necesidades y expectativas de los stakeholders para un sistema de software.

🎯 Objetivo principal

Establecer claramente el tipo de apoyo que necesitas del personal que definirá los requerimientos. Su compromiso de participación activa será uno de los factores del éxito del proyecto.

Estrategias de trabajo

📊 De lo general a lo particular

Iniciar con sesiones de trabajo para contexto general, luego detallar con técnicas específicas de indagación.

🔍 De lo particular a lo general

Iniciar con técnicas de recopilación (entrevistas, cuestionarios), luego consolidar en reuniones con usuarios.

⚠️ Principio fundamental

Cualquier estrategia que apliques siempre debe permitirte detallar los requerimientos de manera que no haya duda de lo que se espera del sistema, tanto para el usuario como para el equipo de desarrollo.

4.1 — RECOPILACIÓN

Fuentes de Información

El primer paso es establecer las fuentes de información que se requieren e involucrar al mayor número de participantes clave.

👥 Stakeholders

Personas de la organización que influyen directa o indirectamente en los requisitos del sistema.

  • Clientes
  • Gerentes
  • Operadores
  • Asistentes
  • Equipo de desarrollo

Fuente principal de información

📄 Documentos

Información organizacional existente.

  • Políticas
  • Estándares
  • Procedimientos
  • Guidelines
  • Manuales de sistemas heredados

Útil para automatizar procesos manuales

💻 Sistemas en operación

Sistemas actuales de la empresa para procesos administrativos u operativos.

  • Funciones eficientes a replicar
  • Métricas de desempeño
  • Casos de uso existentes

Base para comparación y mejora

4.1 — RECOPILACIÓN

Sesiones de Trabajo

Las reuniones con stakeholders son particularmente efectivas porque permiten escuchar diferentes puntos de vista sobre lo que se espera del software.

🎯 Meta de las sesiones (Pressman, 2010)

"Identificar el problema, proponer elementos de la solución, negociar distintos enfoques y especificar un conjunto preliminar de requerimientos en una atmósfera que favorezca el logro de la meta."

Requisitos para participantes

✅ Perfil adecuado

  • Conocimiento de los procesos
  • Actitud propositiva y abierta
  • Capacidad de tomar decisiones
  • Disponibilidad de tiempo

❌ Problema común

Gerentes envían personas no clave para impactar menos la operación.

⚠️ El ingeniero de requerimientos debe detectar esto desde el inicio o será una pérdida de tiempo.

4.1 — RECOPILACIÓN

Facilitación de Sesiones de Trabajo

Rol del ingeniero de requerimientos

Es responsabilidad del ingeniero ser el facilitador de las reuniones:

🎭 Responsabilidades

  • Aclarar expectativas
  • Establecer reglas de comportamiento
  • Mantener motivados a los participantes
  • Guiar hacia la meta propuesta

🏢 Logística necesaria

  • Lugar acondicionado
  • Pintarrón y marcadores
  • Post-it y rotafolio
  • Hojas blancas y bolígrafos
  • Proyector

Metodología recomendada (Pressman, 2010)

1
Comenzar con una declaratoria general del problema para contextualizar (puede revisarse antes de la sesión).
2
Solicitar a participantes describir: elementos del ambiente, funciones, procesos, resultados, restricciones, reglas de negocio y criterios de desempeño.
3
Comparar, analizar, eliminar y agregar características mediante ejercicio de consenso.
4
Consolidar en un documento preliminar de especificaciones.
4.1 — RECOPILACIÓN

Miniespecificaciones

Algunas características del sistema requieren descripciones más detalladas llamadas miniespecificaciones.

🎯 Propósito

  • Aclarar funciones críticas del sistema
  • Facilitar comprensión del equipo de desarrollo
  • Base para validación por el usuario

👥 Proceso de elaboración

  • Elaboradas por grupo reducido de personas
  • Conocen a fondo los pasos del procedimiento
  • Analizadas y complementadas por el resto del equipo
  • Visión más amplia y estable
📋 Contenido típico de una miniespecificación

Descripción detallada paso a paso de un proceso crítico, incluyendo: entradas, salidas, reglas de negocio, validaciones, casos excepcionales y criterios de aceptación.

💡 Ejemplo

Para Davisnet®: una miniespecificación del proceso de "Lectura y almacenamiento de datos del sensor de temperatura" detallando frecuencia de muestreo, validación de rangos, manejo de errores de comunicación, y formato de almacenamiento.

4.1 — RECOPILACIÓN

Técnicas de Recopilación de Información

Estas técnicas permiten recuperar información que detalle de forma completa y exhaustiva los requisitos del sistema. Son complemento de las sesiones de trabajo.

✅ Principio de flexibilidad

Puedes utilizar una o varias técnicas dependiendo de la situación y el tipo de información que necesites recolectar.

💬 Entrevista

Sesión uno a uno entre ingeniero y stakeholder

📋 Cuestionario

Información masiva en poco tiempo

💡 Lluvia de ideas

Creatividad en grupo sin restricciones

👁️ Observación

Experiencia vivencial del proceso

🖥️ Análisis de interfaz

Interacción usuario-sistema

🎯 Método Delphi

Consenso de expertos anónimos

4.1 — TÉCNICAS

Entrevista

Una entrevista es una sesión uno a uno entre el ingeniero de requerimientos y un stakeholder.

📝 Preparación

  • Preparar con suficiente anticipación
  • Listar serie de preguntas
  • Investigar el contexto del entrevistado
  • Definir objetivos claros de la sesión

💬 Durante la entrevista

  • Profundizar en aspectos importantes
  • Encontrar necesidades ocultas
  • Adaptarse a las respuestas
  • Tomar notas detalladas
⚠️ Cuándo usar entrevistas

Recomendable solo cuando sea necesario recabar más información que puedes obtener de pocos usuarios, dado que implica mayor tiempo y el proceso es lento.

💡 Ejemplo Davisnet®

Entrevistar al jefe de soporte técnico para entender problemas actuales con consultas telefónicas de clientes sobre lecturas de sensores.

4.1 — TÉCNICAS

Cuestionario

Los cuestionarios se generan cuando se necesita obtener información masiva en poco tiempo.

✅ Cuándo usar cuestionarios

Útiles para:

  • Entrevistar a muchas personas con el mismo perfil
  • Personas que realizan la misma función
  • Confirmar información que ya se tiene
  • Analizar una opinión general del sistema

📋 Tipos de preguntas

  • Abiertas: respuesta libre
  • Cerradas: opciones predefinidas

Considerar: objetivo a alcanzar y tiempo de análisis de respuestas

⚠️ Desafíos (Pohl y Rupp, 2011)

La creación de un cuestionario adecuado es:

  • A menudo difícil
  • Consume mucho tiempo
  • Requiere conocimiento profundo del dominio
  • Necesita pautas psicológicas
💡 Ejemplo Davisnet®

Cuestionario a 200 clientes actuales preguntando: frecuencia de consulta de datos, dispositivos que usan, funciones deseadas en la web, nivel de satisfacción con sistema actual.

4.1 — TÉCNICAS

Lluvia de Ideas y Observación

💡 Lluvia de ideas (Brainstorming)

Grupo de 5 a 10 personas generando ideas sin restricciones.

1
Cada participante escribe ideas libremente en una hoja (sin restricción)
2
Expresan una idea por turno, sin explicar, que se anota en pintarrón sin juzgar
3
Una vez anotadas todas, el autor explica cada una
4
Se eligen las mejores en consenso y se crea informe

Útil para: involucrados de diferentes grupos, formas creativas/innovadoras, mecanismo de colaboración.

👁️ Observación

🏭 Observación de campo

El ingeniero acompaña al usuario en su lugar de trabajo, tomando nota de los pasos del procedimiento.

🎓 Observación de aprendiz

El usuario lleva al ingeniero "de la mano" a través del proceso para que aprenda cada paso.

Beneficio: Sentido vivencial, sensibilización sobre necesidades del día a día.

4.1 — TÉCNICAS

Análisis de Interfaz y Método Delphi

🖥️ Análisis de interfaz

Análisis sobre cómo el usuario interactúa con un sistema a través de su interfaz gráfica.

🎯 Objetivo

Encontrar la mejor manera para que un usuario pueda ingresar, manipular y sacar información del sistema de forma ágil, consistente y sin errores.

💡 Ejemplo

Si el sistema es para un restaurant o estación de maquiladora, un monitor touch screen puede ser más útil que un teclado para ingresar valores.

Para Davisnet®: analizar si dashboard debe ser responsive (móvil/tablet), widgets configurables, gráficas interactivas vs tablas estáticas.

🎯 Método Delphi

Técnica basada en obtener información de expertos a través de cuestionarios iterativos y anónimos.

1
Expertos contestan primer cuestionario sobre funciones del sistema
2
Ingeniero recopila y genera segundo cuestionario con resumen de juicios (anónimo)
3
Expertos reevalúan sus opiniones al ver el conjunto
4
Se llega a un consenso sin influencia de jerarquías o personalidades dominantes
4.2 — HERRAMIENTAS

Herramientas de Soporte

Las herramientas que puede utilizar un ingeniero de requerimientos están relacionadas con el modelado de ideas, que permiten expresar información de manera ágil y sencilla.

💡 Ejemplo

Si necesitas explicar la arquitectura tecnológica de la organización a un grupo de usuarios, lo más sencillo es simplificar la información a través de un diagrama o modelo gráfico.

🧠 Mapas mentales

Representación gráfica de conceptos y relaciones

🎥 Audio y video

Grabaciones de procesos y operaciones

📋 Casos de uso

Secuencias de acción paso a paso

✏️ Bocetos

Dibujos rápidos de interfaces

👤 Escenarios persona

Definición de usuarios tipo

🎬 Storyboard

Secuencia visual de interacciones

4.2 — HERRAMIENTAS

Mapas Mentales y Grabaciones

🧠 Mapas mentales

Representaciones gráficas de conceptos y sus relaciones en torno a una idea principal.

📊 Estructura

  • Parecidos a una red neuronal
  • Ideas centrales → brazos gruesos
  • Ideas secundarias → brazos delgados
  • Facilitan ver relaciones

✅ Utilidad

Herramienta útil cuando se desea expresar ideas y sus relaciones de forma visual y jerárquica.

Ejemplo: mapa de funcionalidades del sistema Davisnet® con ramificaciones por tipo de usuario.

🎥 Audio y grabaciones en video

✅ Ventajas

Herramienta útil en observación de campo. Permite analizar con detalles los movimientos y acciones que realiza un operador.

⚠️ Problema

Suelen modificar la conducta de las personas que saben que son grabadas o incluso incomodarlas, produciendo resultados sesgados.

4.2 — HERRAMIENTAS

Casos de Uso y Bocetos

📋 Modelado de secuencias de acción (Casos de uso)

Documento que expresa paso a paso las acciones que realizarán los usuarios utilizando el sistema.

✅ Ventajas
  • Ampliamente utilizada en la industria del software
  • Mecanismo de validación de requerimientos
  • El mismo cliente puede usarlos
  • Serán explicados más adelante en este curso

✏️ Bocetos (Sketches)

🎨 ¿Qué son?

Dibujos burdos que expresan una función rápida, simulando lo que hará el sistema o cómo podría verse su interfaz gráfica.

✅ Ventajas

  • Muy sencillos de usar
  • No importa la calidad del dibujo
  • Importa la idea que transmite
  • Cualquier persona puede generarlos
  • Aclaran la interfaz del sistema
💡 Ejemplo Davisnet®

Boceto de dashboard web mostrando: gráfica de temperatura de últimas 24h, alertas de sensores, selector de estación, exportar datos.

4.2 — HERRAMIENTAS

Escenarios Persona y Storyboard

👤 Escenarios persona

Herramienta que define a un usuario (persona) con características detalladas sobre quién es, qué hace y su ambiente de trabajo.

📝 Ejemplo

Janeth López es una ingeniera capturista de datos que ingresa órdenes de compra de productos. Cada orden la ingresa en 30 minutos (promedio) y 1 de cada 5 órdenes tiene errores que provocan malestar en el cliente. Janeth trabaja 8 horas diarias, 6 días a la semana.

✅ Utilidad

Permite a los stakeholders entender requerimientos concretos que ayudarán a este usuario, en lugar de tratar con requerimientos abstractos y superficiales.

🎬 Storyboard

Herramienta visual que mezcla bocetos con escenarios-persona. Describe una situación de interacción particular entre el usuario y el sistema.

✅ Ventajas
  • Analiza situaciones complejas de manera sencilla
  • Inspira creatividad e innovación
  • Visualización de flujos de trabajo
💡 Ejemplo Davisnet®

Persona: "Miguel Fernández, agricultor de 55 años, usa smartphone, revisa datos 3 veces al día desde el campo para decidir riego."
Storyboard: Secuencia de Miguel abriendo app → seleccionando campo → viendo humedad del suelo → tomando decisión de riego.

4 — DOCUMENTACIÓN

Productos de la Indagación

El resultado de todo el trabajo debe estar debidamente documentado. Pressman (2010) propone el siguiente listado:

📄 Documentos iniciales

  • Enunciado de la necesidad y su factibilidad
  • Alcance acotado del sistema
  • Lista de clientes, usuarios y participantes
  • Descripción del ambiente técnico

📋 Requerimientos detallados

  • Lista de requerimientos (organizados por función)
  • Restricciones del dominio aplicables
  • Conjunto de escenarios de uso
  • Prototipos desarrollados
✅ Importancia de la documentación

Estos productos de trabajo son la base para las siguientes fases del proyecto: análisis, diseño, implementación y validación. Sin documentación adecuada, el proyecto carece de dirección clara.

CASO DE ESTUDIO

Davisnet® — Resolución

Retomemos las preguntas del inicio:

❓ Pregunta 1: ¿Cuál sería el primer paso?

Respuesta: Establecer las fuentes de información necesarias e identificar a los stakeholders clave: clientes (agricultores, aficionados), equipo técnico de Davisnet®, gerencia comercial, equipo de soporte, usuarios de sistemas actuales.

❓ Pregunta 2: ¿A quién consultar?

Respuesta: A múltiples stakeholders:

  • Clientes actuales — qué funcionalidades necesitan
  • Equipo técnico — especificaciones de sensores, protocolos de comunicación
  • Soporte al cliente — problemas frecuentes, consultas comunes
  • Gerencia comercial — objetivos de negocio, diferenciación competitiva
❓ Pregunta 3: ¿Qué técnica usar?

Respuesta: Combinación de varias:

  • Sesiones de trabajo — contexto general con equipo interno
  • Entrevistas — con clientes clave y equipo técnico
  • Cuestionarios — para base amplia de clientes actuales
  • Casos de uso — para validar funcionalidades con usuarios
  • Bocetos/Prototipos — para dashboard web
🎯 EJERCICIO 1

Práctica: Fuentes y Técnicas

📝 Instrucciones

Selecciona la respuesta correcta para cada pregunta.

🎯 EJERCICIO 2

Práctica: Sesiones y Miniespecificaciones

📝 Instrucciones

Completa los espacios en blanco.

🎯 EJERCICIO 3

Práctica: Técnicas de Recopilación

📝 Instrucciones

Relaciona cada situación con la técnica más apropiada.

🎯 EJERCICIO 4

Práctica: Herramientas de Soporte

📝 Instrucciones

Completa los espacios en blanco.

BIBLIOGRAFÍA

Fuentes y Recursos

📚 Plataforma Canva — Universidad Tecmilenio

Tema 4: Indagación de Requerimientos. Contenido del curso de Ingeniería de Requerimientos de Software. Cubre fuentes de información, sesiones de trabajo, miniespecificaciones, técnicas de recopilación (entrevista, cuestionario, lluvia de ideas, observación, análisis de interfaz, método Delphi) y herramientas de soporte (mapas mentales, casos de uso, bocetos, escenarios persona, storyboard).

📖 Pressman, R. (2010)

Ingeniería del Software: Un Enfoque Práctico. Referencia para metodología de sesiones de trabajo y productos de la indagación de requerimientos.

📖 Pohl, K. & Rupp, C. (2011)

Requirements Engineering Fundamentals. Referencia sobre diseño de cuestionarios y técnicas de elicitación.

¿Preguntas?

Gracias por tu atención

1 / 24